Subject: DLSw Capabilities Exchange Format Proposal

From: [email-masked]
Date: Sun, 13 Feb 94 18:45:45 EST

Wayne,
The following are my initial comments and questions about your proposal.
I should have something to post about GDS id's on Monday.

On the frame format:
- In addition to picking a new SSP message type (which we can do at
  the meeting), we need to decide whether to use the short or long
  SSP header.  Your exchange with SKR suggests we should use the long
  header, but most of its addressing fields are irrelevant for capex.
  Even if we went with the short header, we should probably pick a
  "non-circuit" value for the remote circuit id field.
- I personally would prefer to see the LT length be inclusive, for
  consistency with the larger GDS structure. I will try to get some
  background on why SNA Formats does it both ways, before the AIW.

About specific fields:
- In addition to the vendor id, we might want to consider being able
  to send some vendor-unique DATA at capex time.  Two routers from
  the same vendor may wish to exchange something more than code
  version numbers.
- I would prefer to see the version string be required, with perhaps
  some subfields that contain key architected information in a fixed
  length format (nothing so complex as SNA/MS's product set id, but
  maybe fields for product model, code version).  The identity of a
  partner product is key information that I might want to log in the
  event of an error, and may quite possibly be information we want
  in the DLSw MIB.  For this to be vendor-defined and variable length
  makes such usage difficult.
- Instead of a NetBIOS support CV, at one point Gene Cox was arguing
  for a "supported SAP" list.  The list would serve the dual purpose
  of indicating whether or not NetBIOS was supported, and be a way
  of filtering unnecessary WAN traffic for unsupported SAPs.  Having
  such a list was one of the things that led us to suggest allowing
  "non-negotiation" capex after transport connection initialization;
  it was easy to envision products that allowed dynamic modification
  of supported SAPs.  Could we discuss Thursday if anyone wants to
  do a SAP list (whether or not we allow capex after TC startup)?
- We should discuss (probably in the loop prevention siglet after a
  solution is close to being adopted) what one is to do with the infor-
  mation learned from the Loop Prevention Support CV.  Choon Lee's
  algorithm seems to require that all the routers in a loop implement
  the algorithm, so what does one do upon finding that a new partner
  does not?  It may be too severe to refuse to have a TC with any
  non-LP capable node.
- I agree with those who've noted that byte 3 of the FC Support CV
  isn't needed under my FC proposal.  So the last part of the 06 CV
  description should probably read "if ... indicates either fixed or
  variable window pacing is supported."  You may want to also clarify
  in the 06 description that a node is reporting the window size it
  is capable of receiving on circuits with the partner to which it
  is sending the capex message.

About MAC address exchange:
  My apologies also for not documenting some ideas our team suggested
  in the capex discussion in September.  The rationale for exchanging
  some MAC address information was this:
    Customers sometimes have a small number of highly "popular"
    destination MAC addresses (e.g., servers, FEPs), available through
    a small number of DLSw nodes.  To cut down on network searches
    from many "client" routers, one could take two approaches:
      a) define at each client router the popular mac addresses and
         the remote router IP address(es) that serve them, or
      b) define the popular mac addresses at the routers local to them,
         and have these routers pass these addresses to new partners
         during capabilities exchange (admittedly bending the meaning
         of the term "capabilities exchange")
    Solution (b) is preferable because you are defining local resources;
    you don't have to change a bunch of installed routers to add a new
    "popular" resource.

    This idea was strictly intended for exchange of a small number of
    hand-defined popular MAC addresses (and NetBIOS names, incident-
    ally) at TC-startup time.  It was not for exchanging dynamically
    learned MAC addresses, even those learned by one router before
    TC-bringup with a newcomer to the network.  We felt that the only
    acceptable steady-state usage of this function would be if one node
    permitted dynamic configuration, and needed to pass new sysdef'ed
    information to a partner.

    Some issues worth discussing are:
    - Is this function worth adding to the architecture?  It can be
      argued that popular addresses are cached quickly so all this
      work produces little benefit.  On the other hand, if there are
      many client routers, they must each do a network search at
      least once.
    - Is there a need for a node to report the ability to USE the
      information passed in these 07/08, or 09 CVs?  The simplest
      approach is to say the info is passed along, and each product
      can either use it or not as they wish, to preload the cache.
    - Is it acceptable to have no way to delete the information
      without taking down the TC?  Do we need other architecture about
      how the information is to be used?
    - Do we need both a list and value/mask approach, or is just the
      list adequate?  I.E., do any customers really structure mac
      addresses well enough for value/mask to be worth implementing?
    - If we do decide to keep it, how shall we add NetBIOS support?
      We would probably allow a list of NetBIOS names with some level
      of wildcarding.

About the capex protocol:
- What sort of time value did you have in mind to wait before
  declaring a partner non-capex-capable?  I assume the timer would
  be cancelled by receipt of an SSP message other than "capex", i.e.,
  our rule is this must be the first message sent.  Do you feel the DLSw
  standard should state a time value, or a range, or leave all this to
  each product's implementation?
- It seems that the exchange philosophy is "I tell you about me,
  you tell me about you, and that's the end".  We haven't discussed or
  defined any negotiation mechanism.  So far, this seems to be an
  adequate approach.  But it does mean that the first time we hit the
  need for a true negotiation, we will have to define the rules for
  doing so.  Do you feel we should defer this topic or address it now?

I know time is short so you may not have a chance to respond to this
before the AIW, but I wanted to get some of these thoughts out as back-
ground to the meeting anyway.  I look forward to discussing this
Thursday afternoon.

Regards,
Peter

---

From: [email-masked]
Date: Sun, 13 Feb 94 23:58:41 PST

>  "non-circuit" value for the remote circuit id field.

    Yes, most header fields are irrelevant.  We should discuss this
    on Thursday.

>  background on why SNA Formats does it both ways, before the AIW.

    I agree the length should be inclusive.  I'd rather that we be
    right than consistent with SNA :-).

>  the same vendor may wish to exchange something more than code

    Sounds like a good idea.

>  makes such usage difficult.

    The reason I made it optional and without structure is that all
    vendors name their releases quite differently.  I agree it's not
    worth the headache to achieve something like Product Set Id.
    I like your comments ... especially the DLSw MIB part.  Let's
    discuss on Thursday.

>  is sending the capex message.

    Just trying to hit a moving target :-).

>    you don't have to change a bunch of installed routers to add a new

    Plus, you don't have as many routers to configure with this local
    information.  I think this is what I captured in the MAC Address
    List CV.

>    information to a partner.

    Agreed.  DLSw Capabilities Exchange doesn't want to get into the
    business of issuing link-state updates to all partipating routers
    whenever new MAC addreses are discovered!  It's a one-shot deal.

>      addresses well enough for value/mask to be worth implementing?

    Normally, the answer is no.  But then, we've seen some who are
    AR (see me at AIW!).

>ground to the meeting anyway.  I look forward to discussing this

    Thanks for the feedback.  I'll capture all of this for discussion
    on Thursday.

Wayne